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Abstract: Social network platforms are increasingly becoming identity providers and a media for showing multiple 
types of activity from third-party web sites. In this article, we analyze the services provided by seven of the 
most popular social network platforms. Results show OAuth emerging as the authentication and authorization 
protocol, giving support to three types of APIs, client-side or Javascript, server-side or representational state 
transfer (REST) and streaming. JSON is the most popular format, but there a considerable variety of resource 
types and a lack of representation standard, which makes harder for the third-party developer integrating with 
several services. 



1 INTRODUCTION 

Popular social network platforms are leveraging iden- 
tity services. They provide authentication commodi- 
ties, relieving third-party websites, applications and 
services from managing user data. They are also an 
increasingly important media. Using already exis- 
tent identity providers can improve the engagement 
of users in those third-party sites. Through APIs, 
these providers allow third-party applications to con- 
nect with the activity streams of the users and insert 
new stories created by the use of the third-party ap- 
plication or service. Nowadays it is not strange to see 
brands, companies and products offering strong inte- 
gration with Facebook, Twitter and others providers 
to improve engagement, visibility and impact. 

Web APIs have been used in last years to create 
mashups, a composition of services that facilitate the 
design and development of modern Web applications 



(Ben slimane et al., 2008| l. Nowadays, social network 
platforms are between the most popular Web sites 
(Mis love et al., 2007]l, though their history is very re- 
cent (boyd and Ellison, 2007). 

Ko et al. review social network connect ser- 
vices from Facebook, Google and Myspace (|Ko et al 



2010). They show how these services provide social 



network features to third-party websites, which do not 
have to build their own social network. They easy sign 
in and enrich user data and experience by mashing up 
their own data with the pieces retrieved from the API 



for instance: finding friends in the platform. On the 
other hand, this is also interesting for the provider that 
is now showing new kinds of activity in the streams. 

An attempt to provide a unified connect service 
was made by OpenSocial (Hasel, 2011), a standard 
promoted by Google, Myspace and others, which has 
been adopted to some extend. 

In this article, we provide an in deep analysis of 
current social network connect services. We have re- 
viewed seven popular social network platforms. First 
of all, there is an analysis of OAuth, the protocol used 
by all of them as sign in and authorization technology. 
The OAuth protocol has several versions, modes, per- 
missions that every provider we have analyzed sup- 
ports in a different degree. Besides there is an anal- 
ysis of the available APIs featuring similarities and 
differences between them. Several patters have been 
identified, i.e. client oriented or Javascript, server ori- 
ented or REST and real-time/streaming oriented. We 
enumerate the widget types used in Javascript APIs. 
For REST APIs, we analyze the formats and resource 
representations offered by the social network connect 
services. Finally, we analyze the streaming APIs. 



2 METHOD 



We have reviewed the APIs of seven popular so- 
cial networking services; Faceboolj^] the popular and 
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well known social network platform; Twitteij^] the 
popular microblogging platform; Google-tQ the re- 
cent Google's bet in social networks; Linkedlrj^J the 
social network platform for professional contacts; 
GithutJ^] the most popular platform for developers 
and social code sharing; Myspac^] the former pop- 
ular champion in social networking and Foursquara^l 
the places check-in oriented social network. 

These platforms offer extensive documentation on 
their APIs as well as online tools for testing them. 

2.1 OAuth 

OAuth is the omnipresent "open protocol to allow 
secure API authorization in a simple and standard 
method from desktop web applications"^ It was de- 
veloped by some web enthusiastics in the aim to de- 
velop a common standard for accessing APIs. Version 
1.0 was proposed as a IETF request for comments 
( |Hammer-Lahav, 2010] ). 

OAuth removes an anti-pattern that was appearing 
in web services applications. With the grown of those 
applications, there was a need of a web application to 
access protected resources from others. For instance, 
imagine some private pictures in a photo sharing ser- 
vice, and another web application that prints photos 
and send them to your home. You may want to let the 
printing service access to several private photos in or- 
der to print them for you. Before OAuth, the only way 
to achieve this was sharing the photo-sharing web ser- 
vice credentials to the printing service. The obvious 
drawback of this approach was that the printing ser- 
vice had full access to your account in that photo- 
sharing service. 

OAuth proposes a solution to this problem. When 
the user wants to print the photos, the photo printing 
service will redirect the user-agent to the OAuth han- 
dler of the photo-sharing service. In this step the user 
will authorize the photo-sharing service to provide to 
the third-party app (printing service) access to their 
pictures. Finally the request will be redirected to the 
printing service including an access token parameter. 
Using this provided token the printing service will be 
granted access to the user private photos. 

In April 29, 2009 a security flaw was discovered 
in the protocol [^j A session fixation attack allowed 
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an attacker to pre-build an authorization request and 
inject it to a user to finish it. OAuth version 1.0a was 
released. This security announce was about a year 
before the RFC publication, so the IETF's document 
already has the security fix. Nevertheless, most of the 
APIs still refer to their supported version of OAuth as 
1.0a. 

OAuth 2.0 is the next version of the protocol. It is 
about to be published as RFC by the IETF. OAuth 2.0 
simplifies the protocol. It describes four different au- 
thorization flows, i.e., authentication code, implicit, 
resource owner password credentials and client cre- 
dentials. The first one, authorization code, is suitable 
for clients capable of maintaining the confidentiality 
of their credentials, i.e. web applications that reside 
in a web server. This flow authenticates the client, 
and the authorization token is granted directly to the 
client, it does not pass through the user-agent. The 
second one, implicit flow, is suitable for clients imple- 
mented in a browser, typically Javascript. The access 
token is directly granted to the client, it is not authen- 
ticated neither. The third is similar to the case OAuth 
tries to solve. The client uses the user's credentials to 
take an authorization token though they are used only 
once and are not stored. Nevertheless, this method is 
requested to be the last alternative to be used. Finally, 
client credentials allows a client to manage protected 
resources controlled directly by him in the authenti- 
cation server. 

OAuth 2.0 also describes access token scopes. 
The scope parameter contains a list of space-delimited 
parameters defined by the authentication server. They 
are used to define to which resources the user is grant- 
ing access to the third-party application or service. 

2.2 API types 

Social web platforms support several types of APIs; 
client side or Javascript, web server side or represen- 
tational state transfer (REST) and streaming APIs. 

2.2.1 Client side or Javascript API 

The most straightforward way to integrate third-party 
web sites with social network platforms is through 
Javascript APIs. Social platforms provide Javascript 
libraries that can be included and used in any web 
site. It is an easy way to mashup local content with 
content from the social platform. There are a lot of 
applications that go from the popular "like" buttons 
or authentication to product recommendations based 
on social data. This APIs use OAuth's implicit flow. 
All Javascript APIs use JSON format due to the fact 
that does not need any really parsing step. 



2.2.2 Web server side or REST API 

Web-server-side APIs are oriented to server-based or 
desktop-based clients. They just provide data without 
any view-related content. They all follow the REST 
principles of addressability, stateleness and represen- 
tations ( |Fielding, 2000} |Richardson and Ruby, 2007) . 
REST principles and REST-oriented architectures en- 
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courage the use of standard HTTP verbs (Fielding 
|et al„ 1999| |Dusseault and Snell, 2010) 1; such as 
GET for reading, POST for adding resources, PUT 
for replacing a given resource, PATCH for changing 
an existing resource and finally DELETE for remov- 
ing resources. REST APIs also support a variety 
of representations. Most common formats include 
Javascript's format JSON, XML, and their syndica- 
tion extensions, RSS and ATOM. The resource rep- 
resentations REST API can also provide some com- 
modities or extensions, such as pagination for large 
collections of data, or introspection that allows the 
examination of the resource's metadata. They pro- 
vide each resource with a URL, so their representa- 
tion can be retrieved and they can also be referenced 
from other resources. 

The resources' addresses provided by REST APIs 
can be of different kinds. There can be a single re- 
source URL scheme, or divided by resource type. In 
the case of a single URL scheme, the resource's rep- 
resentation provides a field declaring the kind of re- 
source. 

As is expected, every social network has a re- 
source type to represent the user. Another metric we 
have used is comparing these fields to see if they fol- 
low any standard, which could be interesting to pro- 
vide a uniform interface to the third-party developer 
that uses two or more social network providers. 

2.2.3 Real time or Streaming API 

The other kind of API provided by social network 
platforms is the streaming API. Unlike the former two 
APIs, in which the client request the platform for data, 
this goes the other way. The client subscribes to the 
platform, which pushes data to the client. This API is 
suitable for real time applications. 



3 RESULTS 



On this section, we present the result of the anal- 
ysis of the seven social network platforms mentioned 
above. Figure [T] shows a summary of these results. 
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Figure 1 : Analysis of the connect services of seven of the 
most popular social network platforms 



3.1 OAuth 

While all the platforms support OAuth, the versions 
are currently divided between 1 .0a (Twitter, Linkedln 
and Myspace), and 2.0 (Facebook, Google+, Github 
and Foursquare). Claims from users can be found in 
developer forums asking providers to support version 
2.0, so it is probable that version 2.0 is implemented 
by all the platforms in the short term. 

Between the platforms providing version 2.0, the 
support for authentication flows is disparate. All of 
them implement the web server/authentication code 
flow, giving support to web applications. The next 
one supported is the implicit flow, primary used in 
the context of Javascript applications. This is im- 
plemented by three of four platforms. Even though 
Linkedln claims to be using OAuth 2.0 in their 
Javascript API, their implementation is not standard, 
so it is not considered as that. Finally, client creden- 
tials flow is only supported by Facebook. They use it 
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to provide third-party applications access to pending 
requests (apprequests) in the Facebook platform. 
They are the clear champion in OAuth 2.0 implemen- 
tations. 

Regarding OAuth scopes, their definition 
is very disparate and significant. Facebook 
defines more than 60 different scope types, 
such as user_about jne, f riends_about_me, 
user_activities, f riends_activities, 

user _birthday, f riends_birthday, etc. Most 
of them are classified in information from a user and 
information from his friends. Many of the scopes 
are related to the profile items, many others with 
collection items types like pictures, videos, etc. The 
special scope manage_pages provides an access 
token for impersonating pages. It is way of using the 
API impersonating the page. A complete reference 
on permissions can be found onlina^M On their side, 
Google+ has a full variety of OAuth scopes^] They 
are providing a different namespace of permissions 
for each Google application (Analytics, Blogger, 
Calendar, Gmail, etc.), so their architecture is more 
modular than Facebook's. Github support only 4 
types of scopes^] (user, public_repo, repo, gist), 
which are very focused on their application area: 
social coding. Finally, Foursquare do not use OAuth 
scopes. 

3.2 APIs 



comment about an activity, activity feeds and recom- 
mendations, as well as the login and register buttons. 
Twitter has the "tweet this", to publish a new tweet 
about the content of the third-party web site, or the 
tweet content that displays the number of tweets about 
the page. Github provides a "fork me on github" but- 
ton that points to the open source repository. 

3.2.2 Web server side or REST API 

HTTP verbs Though the REST principles suggest 
using an HTTP per action, this issue is followed to 
different degree by current social network platforms. 
In one side it is Google+, that supports only read- 
only operations through GET. We expect that they 
support write operations soon. The next group of 
APIs include Twitter and Foursquare. These plat- 
forms only use GET and POST. They both support up- 
dating and deleting operations, but they are performed 
using POST. Facebook follows, using the DELETE verb. 
Updating is rare in Facebook, but it is supported via 
POST. Linkedln and Myspace perform these opera- 
tions with a more appropriate HTTP verb: PUT, which 
was designed for operations updating resources. Fi- 
nally, Github is the champion of this category, in- 
troducing yet another HTTP verb: PATCH. It is used 
for updating only selected fields from a resource, in- 
stead of PUT which is intended to update the whole 
resource. 



3.2.1 Client side or Javascript API 

Almost all the platforms provide a login button. This 
feature allows the third-party application delegating 
authentication and profile information to the social 
network. It is implemented by Facebook, Twit- 
ter, Google+, Github and Linkedln. In the case of 
Google+, the login plug-in comes from Google ac- 
counts; this authentication service is not exclusive 
from Google+ and is used in every single Google 
product. 

Another popular functionality is the "like" but- 
ton, that allows users to post one site to their so- 
cial network at the same time they are supporting it, 
since they are working towards a model where more 
likes means more quality. This is supported by Face- 
book (like), Google+ (+7) and Linkedln {Share this 
in Linkedln). There are other buttons available. Face- 
book has the bigger offer, including the send button 
to post to the Facebook wall, comments plug-in to 
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Resource representations JSON is the om- 
nipresent representation format, supported by every 
analyzed social network platform. It fits very well 
with Javascript APIs. Some of the platforms, such 
as Facebook, Google+, Github and Foursquare only 
support this format. Mostly all the platforms also 
support JSONP, allowing the API users to add a 
callback to JSON calls and avoid restrictions related 
to same origin policies (Oeh lman et al., 201 1] >. XML 
is supported as second format by Linkedln and 
Myspace. Finally, Twitter is the champion in this 
category, supporting also XML derived formats such 
as RSS and ATOM. 

The resource types supported by each network 
vary from 3 by Google+ to more than 25 by Face- 
book. The are very different and depend on the focus 
of the social network. For instance, Github has repos- 
itories, commits and forks, while Foursquare support 
venues and checkins. 

Nevertheless, all of the social network platforms 
support the user resource, which represent the users in 
fihe platform. We have analyzed the JSON represen- 
tation of these resources. The results show that there 
is only one parameter in common: the id. All the 



other parameters are totally different in all networks. 
Figure [2] shows this issue. It gathers name-related pa- 
rameters in each social networks. It is representative 
how there is not even two social network services us- 
ing the same parameters for user names. The rest of 
resource fields are even more disparate. 

Something similar happens with resource pagina- 
tion. Every social network uses different parame- 
ters for requests (e.g. limit, offset, page, count, 
per_page) and response (e.g. previous, prev) 

Resource addresses The common case in REST 
APIs is providing separate end-points for resources. 
Facebook is the only network that provides a single 
API address replaced their old-traditional REST API 
for the new Graph AP^ It is a single interface to 
all the objects they manage. They also use the Open- 
graph protocol^] for adding metadata to the HTML 
of web pages, using the meta tag in the HTML's 
head. This way you can describe metadata like 
title, image, url, but it is redundant information, 
since even the Facebook's parser is able to obtain this 
information from other means (standard HTML tags). 
An interesting feature of the Opengraph is that Face- 
book uses this data to connect with Facebook applica- 
tions and give admin permissions to users, through a 
couple of specific tags fb : admins and fb : app_id. 

3.2.3 Real time or Streaming API 

Real time APIs allow third-party applications sub- 
scribing to updates from the social network platform. 
The most real-time of the APIs is Twitter's. They al- 
low to get opened an HTTP connection and receiving 
a streaming of JSON objects, without closing the con- 
nection. 

On the other hand, Facebook, Foursquare and 
Myspace support their platform performing HTTP re- 
quests to a third-party endpoint when a new event 
must be notified. Facebook uses an standard here, 
pubsubhubub [^j while Foursquare requires the con- 
sumer to register on their web and using HTTPS. 
Posts are performed using JSON. 



4 DISCUSSION 

All the social network connect services analyzed 
use OAuth at least in version 1.0a. The ones that use 
2.0, they all implement web server support, and most 
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of them client-side support. Authorization scopes are 
very particular to each API and there are not enough 
cases to obtain patterns. Nevertheless, we can observe 
two different models in architecture, Facebook's and 
Google's. While Facebook has a lot of different per- 
missions, due to the centralized nature of their ser- 
vice, Google uses URI's in scopes, because of their 
decentralized architecture of services. This matter 
provides Google with better data isolation and more 
privacy. It is also interesting how they ask the user for 
permissions in both cases, for Google it seems to be 
enough asking for "Agenda permissions", Facebook 
on the other hand translates a list of scopes in blocks 
of user friendly text. 

We also want to point to the fact that the change 
from other authentication solutions, like OpenID, to 
OAuth makes things harder to other identity services. 
OpenID uses URI identifiers, so all the services were 
at the same level. With OAuth, the third-party de- 
veloper must put a sign in button for every identity 
provider he is willing to support. Nevertheless, this 
issue was already appearing in OpenID implementa- 
tions, where there were special buttons for most pop- 
ular providers besides the uniform OpenID identifier 
field. 

Regarding Javascript APIs, they are the quickest 
way of integrating a third-party applications with a 
social network services. We can see authentication 
widgets being very popular, with the ability to import 
authentication, profile information and even contacts 
to a third-party. Other plug-ins that are also very pop- 
ular are the ones providing the ability to post to one's 
stream, both in the simpler form of likes as well as 
a more personal posts. Google uses the information 
of their +1 button to improve searches on their main 
product (searcher) that now will show the results that 
our friends recommend as featured entries. The use of 
Google +1 button show us how the information gen- 
erated by the users in social network can be used, and 
is currently being used to improve user experience, 
of course privacy needs to be respected and courts all 
over the world are trying to define clear boundaries. 
Facebook is also the winner in this category with a 
wide range of plug-ins. 

REST APIs are diverse and do not follow a clear 
standard, which makes things harder to the third- 
party developer that wants to integrate with several 
services, because he needs a specific library for all 
of them. The support for REST principles in HTTP 
verbs seems to be disparate, with some of them sup- 
porting them versus other of them overloading POST. 
The JSON format is clearly the preferred in web ser- 
vices. Resource representations are very disparate 
and their are all focused in their social network field. 
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Figure 2: Id and name related fields in the JSON representation of users. While the id field is a common parameter, there are 
not two social network services using the same fields for names. 



This is true even for the representation of a common 
resource: the user and also for the pagination exten- 
sions along all the social network services. We think 
a standard should emerge in this field, maybe the Ac- 
tivity Streams [^] standard could be an option where 
OpenSocial has not been. 

In a very different direction we have Paul Kin- 
lan's (Google Developer Advocate) webintents. We- 
bintents ideaP^lrevolves around the fact that APIs are 
further than ever to be standard but the need of using 
them is rapidly increasing. Webintents mimics An- 
droid intents where we "invoke" other apps to make 
an specific task, then the app returns the results that 
the original app uses to any purpose. If we could do 
the same on the internet there would not be a reason 
to rewrite thousands of already existing APIs. Webin- 
tents declare the services that our API provides and 
other apps can use by invoking us, just by knowing 
the API end-point. 

Finally, it is worth mentioning how technology is 
evolving from request based APIs to push based APIs. 
Nowadays when we constantly update our Twitter or 
Facebook applications we are generating alongside 
the other millions of users an overwhelming amount 
of refresh requests that are not that different from a 
distributed denial of service (DDoS) attack. Due to 
this fact, developers and social networks implemented 
different techniques such as AJAX or long polling. 
But the optimal solution is creating a duplex chan- 
nel between client and server, so it is easy to justify 
the appearance of technologies such as push notifica- 
tions, like Twitter's streaming API shown above, and 
HTML5 websockets[3 



5 CONCLUSION 

Social network platforms are becoming identity 
providers and media for communication. Their ser- 
vices are increasingly being used by third-party web 
applications. For an analysis of this services, we 
can see OAuth as an emerging standard for authen- 
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tication and authentication, giving support for client- 
side Javascript APIs and server-side REST APIs. 
Javascript plug-ins are increasingly popular and pro- 
vide a way to delegate authentication, as well as pro- 
mote third-party services in the social network plat- 
form. Server-side APIs follow REST principles, use 
JSON formats and do not follow any standard for re- 
sources representation. Streaming APIs are getting 
more popular to optimize information transmission. 
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